1. Field of the Invention
This invention relates to the field of computer software, and particularly to methods of creating software components that can be used in different systems with minimal modification.
2. Description of the Related Art
Creating and debugging software code has been and continues to be a very labor-intensive and expensive process. As a result, efforts have been made on many fronts to create "re-usable" code; i.e., code that can function as designed--without modification--in a variety of systems, thereby minimizing the amount of new code that must be created for a given system. As used herein, a "system" refers to software designed for a particular application.
"Object-oriented programming" (OOP) is one technique that facilitates the re-usability of software code. OOP produces application programs that are very modular, and the resulting modules of code can presumably be plugged into other applications. This presumption generally proves to be true for lower level objects, such as an abstract data structure. However, OOP techniques do not necessarily lead to good re-usability for higher level objects. For example, an "aircraft track" object that maintains the speed and altitude of an aircraft may be difficult to re-use, because the actions taken as a result of the data received by the object are dependent on the specific system in which it is employed. The object might be found, for example, in a civilian air traffic control system or a military command and control system, with different reactions required for the same input data. These responsive actions are system-specific and are typically embedded in the object, making them unsuitable for use in a different system.
An illustration of this problem using a fictitious air defense system is shown in FIG. 1a, which is an "event trace diagram" for such a system. This system is implemented using OOP techniques, with the objects involved in the handling of a new radar report, such as "Radar", "Air Track", "Flying Object", etc. shown across the top of the diagram. "Events", which cause the control of the program to be passed from one object to another, are shown below the objects.
A typical system event trace starts with a "Radar" object 10 receiving a new report, which it relays to the "Air Track" object 12; i.e., the "event" 14 of "Radar" receiving a new report is the stimulus that causes program control to be transferred to "Air Track". "Air Track" 12 sends control to the "Flying Object" object 16, which recognizes the track as a potentially hostile aircraft and transfers control to the "Enemy Aircraft" object 18. "Enemy Aircraft" evaluates the threat, and transfers control to the "Threat" object 20 as a result. "Threat" creates a report, and the report and program control are sent to the "Battle Manager" object 22. "Battle Manager" interacts with other objects, with control ultimately transferred to an "Interceptor" object 24. The "Battle Manager" object also reports status to a "Higher Echelon" object 26.
Using conventional OOP techniques, the control sequences needed to execute the event trace in FIG. 1a are built directly into the objects, i.e., "Radar" will call "Air Track", which will call "Flying Object", and so on. However, by so doing, the re-usability of these objects is compromised, because in a different system, the event trace for dealing with a new radar report may be quite different. This is illustrated in FIG. 1b. This different air defense system requires objects having functions similar to those in the FIG. 1a system, but the event traces are different. Here, the "Air Track" object 32 sends track reports directly to the "Higher Echelon" object 34, and the "Battle Manager" object 36 is invoked by the "Higher Echelon" object. To re-use the original "Air Track" or "Battle Manager" objects (12, 22) in the new system, the control sequences encoded within those objects must be replaced with new ones that will implement the new event traces. Thus, these objects are "re-usable" only after modification, with the modification process repeated each time the object is to be re-used in a new system.
Efforts have been made to isolate the program control tasks from a system's functions. For example, Hatley and Pirbhai, Strategies for Real-Time System Specification, Dorset House Publishing (1988), pp. 59-72, and Ward and Mellor, Structured Development for Real-Time Systems, Yourdon Press (1985), pp. 41-70, discuss the concept of a "controller" that handles program control. However, both of these describe systems designed using functional approaches using structured analysis and structured design, which results in a system architecture that is organized by the specific functions the system has to provide. Unfortunately, the software components created using these approaches remain closely tied to the specific application systems for which they were originally designed, making them difficult to re-use in other systems.